Мы уже немало писали про технологию использования хранилищ VVols (например, здесь и здесь), которая позволяет существенно увеличить производительность операций по работе с хранилищами в среде VMware vSphere за счет использования отдельных логических томов под компоненты виртуальных машин и передачи части операций по работе с ними на сторону дисковых массивов.

Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.

Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.

К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.

Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:

Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.

Таким образом, в новой архитектуре VVols пока не прикрутили технологический процесс соединения стороннего сервера с VVols виртуальных машин и снятия с них резервных копий.

Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.

Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!

Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:

В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).

Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски.

Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:

Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:

Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:

Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.

Недавно мы писали том, что компания Код Безопасности, производитель решений номер 1 для защиты виртуальных сред, выпустила обновление продукта vGate R2 версии 2.8. Эта версия прошла инспекционный контроль в ФСТЭК России и доступна для загрузки и покупки. В обновленную версию vGate R2 добавлены новые механизмы защиты и расширенные функции по администрированию системы. Сегодня мы расскажем о том, как в vGate R2 выглядит рабочий процесс для пользователей в защищенной среде.

Интересный пост, касающийся поддержки VMware Tools в смешнном окружении, опубликовали на блогах VMware. Если вы взглянете на папку productLocker в ESXi, то увидите там 2 подпапки /vmtools и /floppies:

Это файлы, относящиеся к пакету VMware Tools, устанавливаемому в гостевые ОС виртуальных машин. Перейдем в папку /vmtools:

Тут находится куча ISO-образов с данными пакета (каждый под нужную гостевую ОС), файл манифеста, описывающий имена, версии и ресурсы файлов пакета, а также сигнатура ISO-шки с тулзами, позволяющая убедиться, что она не была изменена.

В папке floppies находятся виртуальные образы дискет, которые могут понадобиться для специфических гостевых ОС при установке драйверов (например, драйвер устройства Paravirtual SCSI):

Интересно, что папка productLocker занимает примерно 150 МБ, что составляет где-то половину от размера установки VMware ESXi. Именно поэтому рекомендуют использовать образ ESXi без VMware Tools ("no-tools") при использовании механизма Auto Deploy для массового развертывания хост-серверов.

Самая соль в том, что версия пакета VMware Tools на каждом хосте разная и зависит от версии VMware ESXi. Например, мы поставили на хосте VMware vSphere 5.5 виртуальную машину и установили в ней тулзы. Консоль vCenter покажет нам, что установлена последняя версия VMware Tools:

Однако если у нас смешанная инфраструктура (то есть, состоит их хостов разных версий), то при перемещении машины на хост с более высокой версией, например, vSphere 5.5 Update 2/3, она будет показана как ВМ с устаревшей версией пакета (VMware Tools: Running (Out-of-Date):

Поэтому возникает некоторая проблема в смешанной среде, которую можно решить очень просто - как правило VMware Tools от хоста с большей версией подходят ко всем предыдущим. Например, тулзы от vSphere 6.0 подойдут ко всем хостам до ESXi 4.0 включительно. vSphere 6 Update 1 выпадает из списка (постепенно поддержка старых версий уходит):

Таким образом, лучше всего распространить тулзы от vSphere 6 на все хосты вашей виртуальной инфраструктуры. Для этого создадим общий для всех хостов датастор SDT и через PowerCLI проверим, что к нему имеет доступ несколько хостов, командой:

Get-Datastore | where {$_.ExtensionData.summary.MultipleHostAccess -eq “true”}

Далее создадим на этом датасторе папку productLocker:

в которую положим VMware Tools от ESXi 6.0:

Далее нужно пойти в раздел:

Manage > Settings > Advanced System Settings > UserVars.ProductLockerLocation

и вбить туда путь к общей папке, в нашем случае такой:

/vmfs/volumes/SDT/productLocker

Если вы хотите применить эту настройку сразу же на всех хостах кластера, то можно использовать следующий командлет PowerCLI:

Get-VMhost -Location <cluster name> | Set-VMHostAdvancedConfiguration -Name "UserVars.ProductLockerLocation" -Value "/vmfs/volumes/SDT/productLocker"

Теперь для применения настроек есть два пути: первый - это перезапустить хост ESXi, но если вы этого сделать не можете, то есть и второй путь - выполнить несколько команд по SSH.

Зайдем на хост ESXi через PuTTY и перейдем в папку с /productLocker командой cd. Вы увидите путь к локальной папке с тулзами на хосте, так как это ярлык:

Удалим этот ярлык:

rm /productLocker

После чего создадим новый ярлык на общую папку на томе VMFS с тулзами от vSphere 6.0:

ln -s /vmfs/volumes/SDT/productLocker /productLocker

Посмотрим, что все смонтировалось, командой ls:

Вот таким вот образом можно поддерживать самую последнюю версию VMware Tools в виртуальных машинах, когда в вашей производственной среде используются различные версии VMware ESXi.

Недавно Cormac Hogan написал интересный пост о том, как нужно настраивать "растянутый" между двумя площадками HA-кластер на платформе VMware vSphere, которая использует отказоустойчивую архитектуру Virtual SAN.

Напомним, как это должно выглядеть (два сайта на разнесенных площадках и witness-хост, который обрабатывает ситуации разделения площадок):

Основная идея такой конфигурации в том, что при отказе отдельного хоста или его компонентов виртуальная машина обязательно должна запуститься на той же площадке, где и была до этого, а в случае отказа всей площадки (аварии) - машины должны быть автоматически запущены на резервном сайте.

Откроем настройки кластера HA. Во-первых, он должен быть включен (Turn on vSphere HA), и средства обнаружения сетевых отказов кластера (Host Monitoring) также должны быть включены:

Host Monitoring позволяет хостам кластера обмениваться сигналами доступности (heartbeats) и в случае отказа предпринимать определенные действия с виртуальными машинами отказавшего хоста.

Для того, чтобы виртуальная машина всегда находилась на своей площадке в случае отказа хоста (и использовала локальные копии данных на виртуальных дисках VMDK), нужно создать Affinity Rules, которые определяют правила перезапуска ВМ на определенных группах хостов в рамках соответствующей площадки. При этом эти правила должны быть "Soft" (так называемые should rules), то есть они будут соблюдаться при возможности, но при отказе всей площадки они будут нарушены, чтобы запустить машины на резервном сайте.

Далее переходим к настройке "Host Hardware Monitoring - VM Component Protection":

На данный момент кластер VSAN не поддерживает VMCP (VM Component Protection), поэтому данную настройку надо оставить выключенной. Напомним, что VMCP - это новая функция VMware vSphere 6.0, которая позволяет восстанавливать виртуальные машины на хранилищах, которые попали в состояние All Paths Down (APD) или Permanent Device Loss (PDL). Соответственно, все что касается APD и PDL будет выставлено в Disabled:

Теперь посмотрим на картинку выше - следующей опцией идет Virtual Machine Monitoring - механизм, перезапускающий виртуальную машину в случае отсутствия сигналов от VMware Tools. Ее можно использовать или нет по вашему усмотрению - оба варианта полностью поддерживаются.

На этой же кариинке мы видим настройки Host Isolation и Responce for Host Isolation - это действие, которое будет предпринято в случае, если хост обнаруживает себя изолированным от основной сети управления. Тут VMware однозначно рекомендует выставить действие "Power off and restart VMs", чтобы в случае отделения хоста от основной сети он самостоятельно погасил виртуальные машины, а мастер-хост кластера HA дал команду на ее восстановление на одном из полноценных хостов.

Далее идут настройки Admission Control:

Здесь VMware настоятельно рекомендует использовать Admission Control по простой причине - для растянутых кластеров характерно требование самого высокого уровня доступности (для этого он, как правило, и создается), поэтому логично гарантировать ресурсы для запуска виртуальных машин в случае отказа всей площадки. То есть правильно было бы зарезервировать 50% ресурсов по памяти и процессору. Но можно и не гарантировать прям все 100% ресурсов в случае сбоя, поэтому можно здесь поставить 30-50%, в зависимости от требований и условий работы ваших рабочих нагрузок в виртуальных машинах.

Далее идет настройка Datastore for Heartbeating:

Тут все просто - кластер Virtual SAN не поддерживает использование Datastore for Heartbeating, но такого варианта тут нет :) Поэтому надо выставить вариант "Use datastores only from the secified list" и ничего из списка не выбирать (убедиться, что ничего не выбрано). В этом случае вы получите сообщение "number of vSphere HA heartbeat datastore for this host is 0, which is less than required:2".

Убрать его можно по инструкции в KB 2004739, установив расширенную настройку кластера das.ignoreInsufficientHbDatastore = true.

Далее нужно обязательно установить кое-какие Advanced Options. Так как кластер у нас растянутый, то для обнаружения наступления события изоляции нужно использовать как минимум 2 адреса - по одному на каждой площадке, поэтому расширенная настройка das.usedefaultisolationaddress должна быть установлена в значение false. Ну и нужно добавить IP-адреса хостов, которые будут пинговаться на наступление изоляции хост-серверов VMware ESXi - это настройки das.isolationaddress0 и das.isolationaddress1.

Таким образом мы получаем следующие рекомендуемые настройки растянутого кластера HA совместно с кластером Virtual SAN:

Ну и должны быть добавлены следующие Advanced Settings:

Более подробно об этом всем написано в документе "Virtual SAN 6.1 Stretched Cluster Guide".

Компания VMware выпустила обновление для прошлой версии платформы виртуализации - vSphere 5.5 Update 3. Не секрет, что большое количество компаний еще использует версию 5.5, так как на больших предприятиях процесс апгрейда ПО и лицензий протекает очень медленно. Поэтому данное обновление им будет весьма кстати.

Что нового в VMware vSphere 5.5 Update 3:

• Управление механизмом ротации логов - теперь можно задавать ограничение по размеру лог-файлов в vmx (для каждого лога) и количество хранимых логов.
• Сертификация адаптера PVSCSI – теперь устройство виртуальных дисков PVSCSI можно использовать для кластеров MSCS, а также кластеризации приложений, таких как Microsoft SQL или Exchange. Это позволит существенно повысить производительность по сравнению с адаптерами LSI Logic SAS.
• Поддержка новых процессоров серверов - теперь платформа поддерживает последние поколения процессоров от Intel и AMD. Подробнее об этом написано в VMware Compatibility Guide.
• Аутентификация серверов ESXi в Active Directory – ESXi поддерживает шифрование AES256-CTS/AES128-CTS/RC4-HMAC для коммуникации Kerberos между ESXi и Active Directory.
• Поддержка новых баз данных - теперь vCenter Server поддерживает следующие СУБД:
  • Oracle 12c R1 P2 (12.1.0.2)
  • Microsoft SQL Server 2012 Service Pack 2
  • Microsoft SQL Server 2008 R2 Service Pack 3
• Поддержка новых операционных систем - новые гостевые ОС теперь полностью поддерживаются:
  • CentOS 7.0
  • Oracle Linux 7.0
  • Ubuntu 14.10
  • Windows 10
  • RHEL 6.6
  • RHEL 7 .1
  • CentOS 7.1
  • Oracle Linux 7.1
• File Transfer Log – теперь в лог-файлы пишется информация о файлах, переданных на хост ESXi или загруженных с него через vSphere Web Client или vSphere Client.

Также были обновлены несколько сопутствующих продуктов для виртуальной инфраструктуры. Вот ссылки:

• VMware vCenter Server 5.5 Update 3 [Release Notes] [Скачать]
• VMware ESXi 5.5.0 Update 3 [Release Notes] [Скачать]
• VMware vCenter Orchestrator Appliance 5.5.3 [Release Notes] [Скачать]
• VMware vCenter Site Recovery Manager 5.8.1 [Release Notes] [Скачать]
• VMware vSphere Replication 5.8.1 [Release Notes] [Скачать]
• vRealize Operations Management Pack for MEDITECH 1.0.0 [Release Notes] [Скачать]

Напомним, что в каждом из документов Release Notes есть раздел What's New, где можно узнать о новых возможностях соответствующего продукта.

Как мы недавно писали, в вышедшем обновлении VMware vSphere 6 Update 1 есть полноценное средство обновления компонентов виртуальной инфраструктуры vSphere Update Manager (VUM), доступное для vSphere Web Client. Ранее VUM можно было использовать только из "толстого" (C#) клиента vSphere Client, и это было одной из ключевых причин неиспользования веб-клинта от VMware в крупных инфраструктурах.

Теперь vSphere Update Manager полноценно присутствует как оснастка Web Client:

Кстати, если вы хотите использовать Update Manager в vCenter Server Appliance (vCSA), то вам все равно придется скачать ISO-шник vCenter для Windows, так как VUM находится именно там.

В левом сайдбаре можно выбрать нужный сервер Update Manager и работать с ним. Пройдитесь по настройкам на вкладках:

Далее нужно создать новый базовый уровень (Baseline) по обновлениям. Нажмите зеленый плюсик в разделе Hosts Baselines:

Также базовый уровень можно создать для виртуальных машин (обновления VMware Tools) и виртуальных модулей (Virtual Appliances):

Создадим новый базовый уровень:

Отмечаем правила для обновления виртуальных модулей:

На вкладке Patch Repository вы видите не только список автоматически добавленных патчей для хостов, но и можете добавить патчи вручную через Web Client:

Для разных хостов можно применять разные образы обновлений VMware ESXi (добавляются вручную) и даже делать это одновременно:

В разделе VA Upgrades можно посмотреть доступные версии виртуальных модулей, а удобная функция по клику на ссылку "EULA" в соответствующей колонке позволяет не принимать условия лицензии каждый раз при развертывании. Нажимаем "Go to compliance page":

Попадаем в раздел vCenter, где мы можем привязывать базовые уровни к хостам, сканировать на наличие обновлений, тестировать обновления путем их "отстаивания" на выделенных для целей стейджинга хост-серверах, а также проводить обновление хостов (Remediate):

В контекстном меню Web Client для хостов есть пункт Update Manager, который позволяет вызвать его функции (например, просканировать на наличие обновлений или обновить):

Более подробно об Update Manager для vSphere Web Client можно прочитать вот тут. Материалы статьи взяты тут.

После краткого анонса на прошедшей недавно конференции VMworld 2015, компания VMware объявила о выпуске первого пакета обновления для своей флагманской платформы виртуализации - VMware vSphere 6 Update 1 (включая ESXi 6.0 Update 1 и vCenter 6.0 Update 1).

Что нового появилось в Update 1 (полезного, прямо скажем, немного):

• Customer Experience Improvement Program (CEIP) - возможность принять участие в программе улучшения продуктов VMware (без передачи данных о клиенте).
• Интерфейс Suite UI теперь включен по умолчанию в vSphere Web Client.
• Поддержка SSLv3 теперь отключена по умолчанию.
• vCSA Authentication for Active Directory - теперь виртуальный модуль с vCenter поддерживает только методы шифрования AES256-CTS/AES128-CTS/RC4-HMAC для аутентификации Kerberos между vCSA и Active Directory.
• Поддержка установщика HTML 5 для нового развертывания и апгрейда:
  • Установка с установщиком HTML 5 для целевого vCenrer Server - поддерживается.
  • Апгрейд с установщиком HTML 5 для целевого vCenrer Server - не поддерживается.
  • Апгрейд vCenter Server из командной строки - поддерживается.
• Виртуальный модуль vCSA можно развернуть как напрямую на ESXi, так и через сервер vCenter на хосте ESXI.
• Возможность конвертации vCSA во внешний Platform Services Controller (PSC).
• Интерфейс VMware Appliance Management Interface (VAMI) в виртуальном модуле vCSA теперь вернулся и доступен по ссылке https://[ip-адрес или имя VCSA]:5480.

• Возможность накатывания патчей по URL (по умолчанию указан онлайн-репозиторий VMware).
• Отдельный HTML 5 интерфейс для PSC, доступный по ссылке:

https://[IP-адрес VCSA]/psc

Это нужно для того, чтобы администратор мог работать с конфигурациями Single Sign-On (SSO) и другими связанными функциями, когда vSphere Web Client по каким-либо причинам недоступен.

• Build-2-Build upgrade support - обновлять виртуальный модуль vCSA можно по новой схеме обновлений: не обязательно ставить новый модуль поверх предыдущей версии. Теперь можно смонтировать новый ISO-образ в уже готовую виртуальную машину с vCSA и запустить процедуру обновления.

Скачать VMware vSphere 6 Update 1 можно по этой ссылке.

Также был выпущен VMware vSphere Update Manager 6.0 Update 1. В VUM 6.0 U1 появились следующие новые возможности:

• Наконец-то стал доступен полноценный Update Manager Web Client. Одна из главных причин, по которым пользователи не отказывались от старого vSphere Client для Windows (так как в нем есть полноценный VUM), теперь устранена.

Также в Update Manager появилось следующее:

• libxml обновлен до версии 2.9.2.
• Опция реинициализации СУБД для VUM теперь доступна Update Manager Utility в категории Database Settings.
• Поддержка новых СУБД.
  • Microsoft SQL 2008 R2-SP3
  • Microsoft SQL 2012 SP2 (Standalone и Clustered)
  • Microsoft SQL 2014(Clustered)
• Microsoft XML обновлен на MSXML6.dll.
• Oracle (Sun) JRE package обновлен на версию 1.7.0_80.
• По умолчанию отключена поддержка SSLv3.

Скачивается VMware vSphere Update Manager 6.0 Update 1 вместе с vCenter.

Совсем недавно компания VMware выпустила интересный документ о производительности операций виртуальной инфраструктуры под управлением VMware vCenter 6 для серверов, работающих в кластере HA/DRS - "VMware vCenter Server 6.0 Cluster Performance".

Упор сделан на сравнение производительности свежей версии vCenter 6.0 с предшественником - vCenter 5.5. Напомним, что шестая версия поддерживает до 64 хоста ESXi в кластере и до 8000 виртуальных машин (до этого было 32 хоста ESXi и 3000 виртуальных машин).

Конфигурация тестовой среды была следующей:

Программные компоненты:

Производительность каких операций проверялась:

• Add Port Group
• Remove Port Group
• Clone VM
• Create Folder
• Delete Folder
• Create Snapshot
• Delete Snapshot
• Group Power-On VMs
• vMotion VM
• Power On VM
• Power Off VM
• Reconfigure VM
• Register VM
• Unregister VM
• Relocate VM
• Remove VM
• Reset VM
• Suspend VM
• Resume VM

В результате тестирования были получены следующие результаты:

• vCenter 6.0 показывает лучшую операционную производительность (в количестве операций) до 66% лучше прошлой версии.

• Улучшенная производительность под очень тяжелыми нагрузками.
• Одинаковая производительность как vCenter Server для Windows, так и виртуального модуля vCSA на базе Linux.
• Операции с виртуальными машинами происходят существенно быстрее.

Больше интересных подробностей и графиков вы можете найти в документе.

Продолжаем вас знакомить с анонсами прошедшей недавно конференции VMware VMworld 2015. Напомним наши прошлые новости о продуктах и технологиях VMware:

• Улучшения VMware vCloud Air: Project SkyScraper и другие
• Новые возможности VMware Site Recovery Manager 6.1
• Анонсирован VMware Virtual SAN 6.1 - новые возможности
• Новые возможности VMware Horizon View 6.2 для инфраструктуры виртуальных ПК и поддержка NVIDIA GRID 2.0

Сегодня мы расскажем о VMware Cloud Native Applications - стратегии VMware по распространению облачных приложений в контейнерах. Концепция эта основана на двух проектах, которые, возможно, были известны некоторым из вас ранее - Project Bonneville/Pacific и Photon/Lightwave. О проектах Photon и Lightwave мы уже писали вот тут. А вот про Project Bonneville можно почитать здесь.

Напомним, что Photon - это Linux-платформа с минимально необходимым набором средств для запуска контейнеризованных приложений, средств управления средой и взаимодействия с гипервизором VMware vSphere (сейчас минимальная конфигурация этого дела весит около 25 МБ):

Состоит данная среда из двух компонентов: Photon Controller, управляющий развертыванием новых экземпляров виртуальных машин и аутентификацией пользователей (Lightwave), а также Photon Machine - собственно хост, позволяющий запускать экземпляры виртуальных машин с контейнерами приложений (на базе "микровизора" ESX, совместимого по железу с обычным ESXi):

Сама технология использования контейнеризованных приложений называется vSphere Integrated Containers (VIC), она позволяет на базе Photon OS запускать контейнеризованные приложения в среде VMware, включая приложения упакованные средствами Docker.

Photon Controller использует механизм VMFork (сейчас эта технология называется VMware Instant Clone и доступна в vSphere 6) для создания мгновенных экземпляров виртуальных машин (менее 1 секунды) с нужным приложением по запросу от пользователя. Интересно, что в одном экземпляре ВМ работает только один контейнер приложения, что как бы несколько странно для контейнерной виртуализации, но так себе видит эту тему VMware.

Уверяют, что для этой технологии можно будет использовать те же самые серверы, на которых сейчас работает ESXi.

Средство VMware Photon Controller выйдет уже совсем скоро, а вот закрытая бета VMware Photon Platform и Pivotal Cloud Foundry and Photon Platform (интегрированная инфраструктура Photon в PaaS-платформу от VMware) выйдет ближе к концу года:

Более подробно о VMware Cloud-Native Apps рассказано на этой странице. Ну а для тех, кто хочет погрузиться в технические детали, есть вот такая презентация с VMworld 2015:

На проходящей сейчас конференции VMworld 2015 компания VMware представила новую версию своего решения для виртуализации рабочих мест предприятия VMware Horizon 6.2. Основные нововведения коснулись продукта VMware Horizon View 6.2, отвечающего за виртуализацию ПК и создание VDI-инфраструктуры компании. Напомним, что о новых возможностях решения VMware Horizon View 6.1 мы писали вот тут.

Давайте посмотрим, что нового появилось в VMware Horizon View 6.2:

1. Поддержка архитектуры Cloud Pod для опубликованных приложений (RDS).

Ранее эти функции были доступны только для виртуальных десктопов, теперь же масштабируемая архитектура облачных блоков доступна и для сервисов RDS. Теперь пространство управления доступом пользователей распространяется на уровне датацентра и между датацентрами, включая сильно географически разделенные площадки.

2. Функции HTML Access for Cloud Pod

Теперь на глобальном уровне можно получить доступ к виртуальному ПК одного из подов прямо по ссылке из браузера с поддержкой HTML 5. Для доступа используется протокол Blast.

3. Стали доступны средства балансировки нагрузки RDSH и интеллектуального размещения сессий.

Теперь для определения загрузки хостов и приложений используются счетчики perfmon, а сессии пользователей балансируются между серверами RDSH на основе этих данных. Безусловно, в Horizon View эти функции еще не такие мощные, как в Cirtix XenApp, но видно, что VMware развивается в этом же направлении.

4. Технология Linked Clones для виртуальных машин с сервисами RDS.

Теперь можно использовать View Composer для создания инфраструктуры связанных клонов (Linked Clones) для ферм RDSH. Это позволяет автоматизировать развертывание этих ферм на хост-серверах VMware ESXi, а также централизованно управлять ими, а самое главное - обновлять на уровне мастер-образа.

Эти функции для сервисов RDS пользователи ждали довольно давно.

5. Технология организации доступа Access Point.

Теперь нет необходимости размещать Windows-машину в DMZ, чтобы организовать безопасный доступ пользователей к их виртуальным ПК. В новой версии используется специализированный защищенный модуль на базе виртуального модуля (Virtual Appliance) Linux SLES 11, который можно выставить в DMZ (установка ПО весьма проста).

6. Поддержка однонаправленных трастов.

Теперь наличие двунаправленного траста не обязательно. Это востребовано в крупных инфраструктурах.

7. Поддержка новой версии технологии NVIDIA GRID 2.0.

Более подробно об этом можно прочитать вот тут. Теперь поддерживается новое поколение карт с процессорами Maxwell. Напомним, что ранее это были карточки NVIDIA K1/K2 (архитектура Keppler).

Новые графические карты M60/6 обещают быть в 2 раза более производительными и позволяют разместить до 128 пользователей, требовательных к производительности графической подсистемы, на одном сервере.

Более подробно об этом написано вот тут.

8. Поддержка AMD GPU для режима vDGA.

Мы уже писали, что такое режим vDGA, и почему он производительнее vSGA. Теперь режим vDGA Passthrough полностью поддерживается для карточек AMD. Кстати, эти карточки стоят дешевле, чем у NVIDIA, поэтому можно снизить стоимость такой инфраструктуры в определенных сценариях.

9. Поддержка функции 3D-ускорения для приложений RDS.

Теперь публикуемые через RDSH приложения тоже поддерживают режим аппаратного ускорения vDGA и vGPU (пока только для NVIDIA). Это может оказаться очень полезным и выгодным, в том числе по сравнению с виртуальными ПК.

10. Поддержка vGPU для Linux-десктопов.

Теперь не только Windows-пользователи смогут полноценно использовать функции vGPU от NVIDIA.

11. Перенаправление клиентского диска для VDI и RDSH.

Если раньше это перенаправление работало только для Windows, то теперь можно перенаправить диски Win и Mac клиентов, а также в экспериментальном режиме и для Linux.

12. Поддержка ассоциаций типов файлов для RDSH.

Теперь можно просто открыть файл с помощью опубликованного приложения по клику на него, а не искать из предварительно открытого приложения нужный файл.

13. Поддержка разрешения 4К.

Теперь мониторы с мегаразрешениями (3840x2160) полностью поддерживаются для инфраструктуры виртуальных ПК:

14. Поддержка Windows 10.

Теперь виртуальные ПК поддерживают в качестве гостевой ОС Windows 10, а также последние функции Skype.

Доступность VMware Horizon View 6.2 ожидается в ближайшее время.

Для вас мы четвертый год устраиваем VMware Tour и, что важно, проводим его с доставкой в ваш город. Мы будем очень рады встрече с вами в рамках этого традиционного роуд-шоу и уверены, что вы почерпнете много полезной информации, сможете пообщаться с коллегами, представителями вендоров и ведущих интеграторов — одним словом, проведете время с пользой!

На проходящей сейчас конференции VMworld 2015 было сделано множество интересных анонсов (впрочем, как и всегда). Конечно же, мы расскажем о всех тех, что достойны внимания. Одна из самых интересных новостей - это анонс новой версии решения для создания кластеров хранилищ VMware Virtual SAN 6.1.

Давайте взглянем на новые возможности этого решения:

1. Virtual SAN Stretched Cluster.

Теперь VSAN будет позволять создавать географически "растянутый" кластер хранилищ между датацентрами, продолжая обеспечивать функции отказоустойчивости. Репликация данных при этом работает с синхронном режиме.

2. Virtual SAN for Remote Office / Branch Office (ROBO)

В VSAN теперь появилась возможность развертывать множество двухузловых кластеров хранилищ, которыми можно централизованно управлять из одной консоли отдельного VMware vCenter Server, предназначенного для этой задачи. Этот сценарий подходит для компаний с большим числом небольших филиалов:

3. Virtual SAN Replication with vSphere Replication

Virtual SAN 6.1 теперь может использовать технологию vSphere Replication для асинхронной репликации данных на любые расстояния в комбинации с VMware Site Recovery Manager (SRM), чтобы получилось полностью законченное решения для восстановления инфраструктуры после сбоев.

Например, можно создать синхронно реплицируемый растянутый кластер хранилищ на расстояниях с latency менее 5 мс, а средствами vSphere Replication откидывать данные в географически удаленный датацентр:

4. Поддержка Multi-Processor Fault Tolerance (SMP-FT).

Теперь виртуальные машины, защищенные технологией FT, полностью поддерживаются со стороны VMware Virtual SAN 6.1, то есть кластер непрерывной доступности из виртуальных машин теперь защищен как со стороны вычислительных ресурсов, так и со стороны хранилищ.

5. Поддержка Windows Server Failover Clustering (WSFC) and Oracle Real Application Cluster (RAC).

В новой версии VSAN теперь поддерживаются технологии кластеризации от Oracle и Microsoft. Для Oracle RAC можно запускать несколько экземпляров Oracle RDBMS на одном хранилище. Точно так же можно использовать и кластеры Microsoft WSFC поверх хранилищ Virtual SAN:

6. Максимальная производительность и высокая скорость отклика.

Здесь было сделано 2 серьезных улучшения:

• Поддержка ULLtraDIMM SSD хранилищ, которые втыкаются в канал оперативной памяти (слоты DIMM), работающие с очень быстрым откликом на запись (менее 5 микросекунд). Это позволяет сделать хост All Flash с емкостью на 12 ТБ в форм-факторе блейд-сервера с троекратно большей производительностью, чем у внешних массивов.
• NVMe – интерфейс Non-Volatile Memory Express (NVMe), который был специально разработан для SSD, чтобы максимально распараллеливать операции на программном и аппаратном уровне. В тестах VMware, использующих эту технологию, было получено 3,2 миллиона IOPS на 32-узловом кластере при примерно 100 тысячах операций в секунду на одном хост-сервере ESXi.

7. Virtual SAN Health Check Plug-in.

Теперь плагин, который был ранее доступен только на VMware Labs, стал частью решения VMware Virtual SAN 6.1. Теперь вся необходимая информация о жизнедеятельности кластера хранилищ видна в VMware vSphere Web Client:

8. Virtual SAN Management Pack for vRealize Operations.

Теперь для решения vRealize Operations есть отдельный Virtual SAN Management Pack, который позволяет осуществлять мониторинг кластера хранилищ и своевременно решать возникающие проблемы:

Более подробно о решении VMware Virtual SAN 6.1 можно узнать на этой странице. О доступности решения для загрузки будет объявлено несколько позже.

В ближайшее время мы расскажем еще о нескольких интересных анонсах с VMworld 2015 - stay tuned.

В середине августа мы писали про утилиту VMware ESXi Embedded Host Client, которая возвращает полноценный веб-клиент для сервера VMware ESXi с возможностями управления хостом и виртуальными машинами, а также средствами мониторинга производительности. Разработчики получили очень много фидбэка, в результате чего было решено ударными темпами сделать вторую версию, новые возможности которой мы здесь приводим.

Итак, что нового в VMware ESXi Embedded Host Client 2:

Хост ESXi

• Улучшенное представление производительности в интерфейсе
• Композитная метрика CPU/память на одном графике

Виртуальные машины

• Поддержка снапшотов
• Поддержка отображения консоли в полноэкранном режиме
• Поддержка функции обрезания консоли до удобного представления (shrink)
• Возможность создания гостевой машины с Mac OS

Хранилища

• Полноценный файловый браузер (операции copy/move/delete/create directory/upload/download)
• Возможность зарегистрировать ВМ из контекстного меню виртуальной машины
• Возможность создания/монтирования хранилищ NFS
• Создание и расширение хранилищ VMFS (только для ранее неразмеченных дисков)
• Опреации Mount/Unmount для VMFS

Сетевое взаимодействие

• Вывод правил сетевого экрана (пока в режиме read-only)

Основные возможности

• По двойному клику на заголовок окна - оно увеличивается
• Поддержка перетаскивания границы с зажатым "Alt" для изменения размера окна
• Возможность переопределить локаль (но пока официально поддерживается только en-US)
• Указание таймаута сессии с клиентом

Обновляться очень просто - надо просто обновить один vib-пакет, в котором распространяется веб-клиент для ESXi:

[root@mini:~] esxcli software vib update -v /esxui-3015331.vib
Installation Result
Message: Operation finished successfully.
Reboot Required: false
VIBs Installed: VMware_bootbank_esx-ui_0.0.2-0.1.3015331
VIBs Removed: VMware_bootbank_esx-ui_0.0.2-0.1.2976804
VIBs Skipped:

Скачать ESXi Embedded Host Client 2 можно по этой ссылке.

Компания VMware на днях выпустила мажнорные обновления своих настольных платформ виртуализации - VMware Fusion 8 и VMware Workstation 12. Помимо полной поддержки Microsoft Windows 10 в качестве хостовой и гостевой ОС, в продуктах традиционно появилось много серьезных нововведений, и их в общем-то можно заслуженно считать лучшими на рынке (хотя стоит взглянуть и на Parallels Desktop 11). Напомним, что про возможности прошлых версий VMware Fusion 7 и VMware Workstation 12 мы уже писали вот тут.

Новые возможности VMware Fusion 8:

• Полная поддержка Windows 10 в качестве гостевой ОС:
  • Поддержка Windows 10 Auto Detect и функций Easy Install
  • Поддержка Windows 10 для режима Unity
  • Возможности миграции физической Windows 10 в виртуальную машину
  • Импорт машины Windows 10 на Boot Camp в ВМ
• Поддержка новой версии Mac OS X El Capitan
  • Возможность запуска Mac OS X El Capitan в виртуальной машине
  • Поддержка Mac OS X El Capitan в качестве хостовой системы
• Поддержка новых гостевых ОС:
  • Ubuntu 15.04
  • Fedora 22
  • CentOS 7.1
  • RHEL 7.1
  • Oracle Linux 7.1
  • VMware Project Photon
• Улучшенная поддержка DirectX 10
• Улучшенная поддержка OpenGL 3.3
• Улучшения производительности при приостановке и включении зашифрованных виртуальных машин
• Улучшенные настройки разрешения
  • Возможность установить глобальные настройки разрешения для ресайзинга окон
  • Возможность перекрыть эти настройки для отдельной виртуальной машины
• Интеграции с VMware vCloud Air (только в версии Fusion 8 Pro)
  • Возможность просмотреть инвентори виртуальных машин в облаке
  • Удаленная консоль с мышью и клавиатурой
  • Возможность загрузки локальной виртуальной машины в облако vCloud Air
  • Операции с состоянием ВМ (запуск, останов и т.п.)
  • Улучшенный интерфейс и отзывчивость операций
• Улучшенные функции удаленного управления (только в версии Fusion 8 Pro)
  • Возможность удаленно создать виртуальную машину на платформах VMware vSphere, VMware ESXi и VMware Workstation
  • Просмотр состояния хостов ESXi на одном дэшборде
• Поддержка сети IPv6 NAT (только в версии Fusion 8 Pro)
• Поддержка последних макбуков:
  • Возможность работы с гостевой Windows-машиной на iMac 5K в нативном разрешении
  • Поддержка нового MacBook
• Заглушение эха при голосовых и видеозвонках Microsoft Lync и Skype
• Поддержка USB 3.0 для Windows 7 (с последним драйвером Intel)
• Улучшенный интерфейс: элементы в меню Пуск и мастер создания виртуальных машин
• Добавлено предупреждение для опции "Open your Windows files and web links using Mac Applications", чтобы его замечали пользователи и понимали, что есть такая возможность

Скачать VMware Fusion 8 можно по этой ссылке.

Новые возможности VMware Workstation 12:

• Полная поддержка Windows 10 в качестве гостевой и хостовой ОС:
  • Поддержка Windows 10 Auto Detect и функций Easy Install
  • Поддержка Windows 10 для режима Unity
  • Возможности миграции физической Windows 10 в виртуальную машину
• Поддержка новой версии Mac OS X El Capitan
  • Возможность запуска Mac OS X El Capitan в виртуальной машине
  • Поддержка Mac OS X El Capitan в качестве хостовой системы
• Поддержка новых гостевых ОС:
  • Ubuntu 15.04
  • Fedora 22
  • CentOS 7.1
  • RHEL 7.1
  • Oracle Linux 7.1
  • VMware Project Photon
• Улучшенная поддержка DirectX 10
• Улучшенная поддержка OpenGL 3.3
• Улучшения производительности при приостановке и включении зашифрованных виртуальных машин
• Интеграции с VMware vCloud Air (только в версии Workstation Pro для Windows)
  • Операции с состоянием ВМ (запуск, останов и т.п.)
  • Улучшенный интерфейс и отзывчивость операций
• Поддержка сети IPv6 NAT
• Возможность открепить вкладку с виртуальной машиной одного экземпляра Workstation Pro и перетащить в другую консоль Workstation
• Автоматическая приостановка виртуальных машин при выключении хоста
• Поддержка 4К-мониторов на высоких разрешениях
• Поддержка нескольких мониторов с разным DPI
• Заглушение эха при голосовых и видеозвонках Microsoft Lync и Skype
• Поддержка USB 3.0 для Windows 7 (с последним драйвером Intel)
• Улучшенный установщик виртуальных машин
• Добавлены настройки NAT в Virtual Network Editor на Linux
• Поддержка настройки леворукой мыши на хостах Windows

Скачать VMware Workstation 12 можно по этой ссылке.

Уже где-то год прошел с момента релиза версии 6.1 решения для виртуализации сетей виртуального и физического датацентра VMware NSX. Поэтому VMware давно уже было пора обновить продукт и согласовать его с последними версиями линейки продуктов для серверной и десктопной виртуализации. Как мы все давно ждали, на днях вышла обновленная версия VMware NSX 6.2, где появилась масса нужных новых возможностей.

Приведем здесь основные из них:

1. Поддержка последних версий платформ виртуализации.

VMware NSX 6.2 поддерживает как VMware vSphere 5.5, так и vSphere 6.0. Новые функции в плане сетевого взаимодействия и безопасности между двумя серверами vCenter поддерживаются только для vSphere 6.0.

2. Возможности Cross vCenter Network Virtualization.

В NSX 6.2 поддерживаются окружения, где логические коммутаторы, распределенные логические маршрутизаторы и распределенные сетевые экраны размещены таким образом, что их действие распространяется на объекты с разными vCenter. Официально эта возможность называется Cross-vCenter Network and Security.

Теперь политики фаервола или логических сетевых компонентов могут быть помечены как Universal, что означает, что настройки реплицируются между модулями NSX Manager и будут сохранены при миграции vMotion виртуальной машины на другой хост ESXi, который находится под управлением другого сервера vCenter.

3. Новые универсальные логические объекты сети.

• Universal Logical Switch (ULS) - возможность создания логических коммутаторов, которые объединяют несколько серверов vCenter. Это позволяет создать L2-домен сетевого взаимодействия для приложения в виртуальной машине, которое может "путешествовать" между датацентрами.
• Universal Distributed Logical Router (UDLR) - это логический распределенный роутер, осуществляющий маршрутизацию между объектами ULS, описанными выше. Этот маршрутизатор работает также и на базе географического размещения ВМ.
• Universal IP sets, MAC sets, security groups, services и service groups - все эти объекты поддерживают распределенные структуры с несколькими vCenter.

4. Поддержка VMware vCenter Server 6 с различными топологиями Platform Services Controller (PSC).

Если раньше NSX поддерживала только встроенные сервисы PSC (Platform Services Controller), то теперь поддерживаются различные распределенные топологии (об этом мы писали вот тут). Теперь полностью поддерживаются такие компоненты, как vCenter SSO, license service, lookup service, VMware Certificate Authority и прочее.

5. Поддержка L2 Bridging для Distributed Logical Router.

L2 bridging теперь может принимать участие в распределенной логической маршрутизации. Сеть VXLAN, к которой присоединен экземпляр бриджинга, используется для взаимосоединения Routing instance и Bridge instance.

6. Новый механизм обнаружения IP-адресов для виртуальных машин.

Ранее IP-адреса виртуальных машин обнаруживались по присутствию в них VMware Tools и добавлялись вручную. Теперь есть 2 новых способа добавления адресов: DHCP snooping и ARP snooping (причем присутствие VMware Tools необязательно).

7. Улучшения средств управления и решения проблем.

Тут появились следующие новые фичи:

• Central CLI - единый интерфейс командной строки для обычных и распределенных функций NSX.
• Traceflow troubleshooting tool - утилита, которая позволяет понять, возникла проблема в виртуальной или физической сети, за счет слежения за прохождением пакета через виртуальный и физический сетевой стек.
• Функции Flow monitoring и IPFix теперь можно включать отдельно (раньше можно было только вместе и это создавало много нагрузочного трафика, особенно в больших окружениях).
• Отчет в реальном времени о состоянии управляющих компонентов NSX: состояние связей между NSX Manager и агентом сетевого экрана, NSX Manager и консолью управления, между хостами ESXi и NSX Controller.

8. Улучшения LB Health Monitoring.

Теперь доступен гранулярный мониторинг состояния, который предоставляет информацию о произошедших сбоях, а также отслеживает информацию об изменении состояния компонентов NSX и связей между ними. Помимо этого, также предоставляется информация о возможных причинах сбоев.

9. Поддержка диапазона портов для LB.

Теперь для приложений, которым нужно использовать диапазон портов для LB, есть возможность задать этот диапазон.

10. Прочие улучшения.

• Возможность сохранять тэг VLAN при коммуникациях VXLAN.
• Просмотр активного узла в HA-паре.
• Увеличено максимальное число виртуальных IP-адресов.
• Поддержка vRealize Orchestrator Plug-in for NSX 1.0.2.
• Возможность включения/отключения uRPF check для отдельного интерфейса.
• Улучшения Load balancer health monitoring.
• Прочие улучшения, полный список которых приведен вот тут.

Скачать VMware NSX 6.2 можно по этой ссылке. Документация по продукту доступна вот тут.

Кроме того, VMware NSX версии 6.2 поддерживает инфраструктуру виртуальных ПК VMware Horizon View версии 6.0.1 и боее поздних (другие продукты вы тоже можете добавить в VMware Product Interoperability Matrix):

Про поддержку VMware Horizon View есть также небольшое видео:

Не успели администраторы VMware vSphere нарадоваться полезному веб-клиенту для серверов ESXi, как на сайте проекта VMware Labs появилась следующая интересная штуковина - VNC Server and VNC Client.

Эта штука представляет собой сервер и клиент в виде standalone-приложений для доступа к консоли виртуальных машин в продуктах VMware vSphere и VMware Workstation. Имплементация VNC-протокола уже есть в этих продуктах, за счет нее и работает так называемая MKS-консоль в толстом и тонком клиентах vSphere.

VNC-протокол передает сессию на VNC-клиент к удаленному десктопу, на котором установлен VNC-сервер. Утилита работает из командной строки и не имеет UI, но работает аналогично подобным VNC-пакетам:

Надо отметить, что соединения по протоколу VNC не являются защищенными, поэтому рекомендуется их использовать в VPN-сети или в туннеле SSH.

Возможности VNC-клиента и сервера:

• Оптимизированы для каналов с ограниченной пропускной способностью
• На клиенте консоль сделана в стиле клиентов VMware
• Пользователям доступны дополнительные расширения при соединении с виртуальной машиной VMware напрямую или с VMware VNC Server

VNC Server может быть развернут на Windows, Linux или Mac OS X. VNC Client работает из под Windows и Linux. Скачать VNC Server and VNC Client можно по этой ссылке.

На сайте проекта VMware Labs появилась наиполезнейшая вещь - ESXi Embedded Host Client. Это написанный полностью на JS и HTML 5 веб-клиент для сервера VMware ESXi, который все так долго ждали:

Этот клиент работает только для управления хостами VMware ESXi (его нельзя использовать для управления сервером vCenter). Он позволяет производить следующие операции с хост-сервером и виртуальными машинами:

• Операции с состоянием ВМ (включение, выключение, приостановка и прочее)
• Создание новой виртуальной машины с нуля или развертывание из виртуального модуля OVF/OVA (для OVA поддержка пока ограничена)
• Настройка сервисов времени NTP на хосте
• Отображение информации о машинах, их конфигурациях, событиях, задачах, нотификациях и алертах
• Получение доступа к консоли виртуальной машины
• Настройка сетевого окружения на хосте ESXi
• Настройка расширенных параметров (advanced settings)
• Конфигурация сервисов, работающих на хосте

В принципе, список включает все необходимые операции для хоста без vCenter, которые могут потребоваться в повседневной работе.

Для установки Embedded Host Client просто загрузите VIB-пакет приложения во временную папку и установите его командой:

# esxcli software vib install -v /tmp/esxui.vib

Далее можно без перезагрузки хоста ESXi заходить по следующему адресу и управлять сервером:

https://<адрес ESXi или IP>/ui/

Если у вас ESXi 5.5 или ESXi 6.0, полученный обновлением с версии 5.5, то вам нужно заглянуть сюда. Скачать ESXi Embedded Host Client можно по этой ссылке.

Если вы администратор VMware vSphere со стажем, то наверняка попадали в такую ситуацию: по какой-то причине отключается сервер VMware vCenter (он может работать, но не отвечать на подключения), а с ним вместе недоступна и его база (на том же хосте или на отдельном) - и вам нужно искать хост ESXi с этими ВМ, чтобы поднять всю виртуальную инфраструктуру. А хостов ESXi в кластере у вас может быть несколько десятков.

Можно, конечно, сделать правило DRS для vCenter, чтобы он не перемещался по хостам, но в случае срабатывания аварийного восстановления VMware HA, сервер vCenter вполне может поменять хост, так как HA забивает на правила DRS.

В этом случае может оказаться полезным интерфейс PowerCLI, который позволит найти нужную ВМ по ее имени. Но сначала вам нужно разрешить множественные соединения к нескольким хостам. Делается это следующей командой:

Set-PowerCLIConfiguration -DefaultVIServerMode Multiple -Scope Session

Теперь можно соединиться со всеми серверами одновременно и найти там vCenter. Делается это следующей командой:

connect-viserver @("esx1","esx2","esx3") -user root -password password

Это, конечно, покатит только если у вас на всех хостах ESXi везде одинаковый пароль root. Но если они там разные, то нужно будет для каждого сервера исполнить соответствующую команду.

Далее просто ищем нужную виртуальную машину по ее имени:

(get-vm vCenter01).vmhost
(get-vm SQL01).vmhost

В выводе этих команд будут хосты ESXi, на которых они зарегистрированы. Остается только открыть к ним консоль через vSphere Client и включить эти машины.

Каждый администратор VMware vSphere рано или поздно сталкивается с тем, что хост VMware ESXi выпадает в "Pink Screen of Death" (PSOD - розовый экран смерти):

Причина этого - как правило, аппаратные проблемы сервера (барахлящее оборудование, битые блоки памяти, проблемы с драйверами, в том числе виртуальных устройств, и т.п.). В этом случае полезно погуглить ошибку, но сначала нужно получить дамп ядра (core dump), где сохраняются подробности о причине PSOD.

В VMware vSphere Web Client в представлении Hosts and Clusters нажимаем правой кнопкой на сервере vCenter, далее в контекстном меню выбираем пункт "Export System Logs...":

Далее выбираем интересующий нас хост VMware ESXi:

Затем отчекиваем все галки, кроме CrashDumps:

После экспорта файла открываете его в текстовом редакторе и ищете строчку "@bluescreen":

Ниже вы увидите подробности о произошедшей ошибке:

В данном случае мы видим, что имеет место проблема с драйвером виртуального сетевого адаптера (vNIC) E1000. Можно заменить его на VMXNET3 (как описано в KB 2059053), и проблема уйдет. Ну и прочие подобные ошибки можно гуглить, по PSOD ESXi уже есть много информации на форумах.

Некоторые из вас знают компанию VMTurbo, занимающуюся производством решений для резервного копирования виртуальных машин. На днях VMTurbo выпустила бесплатный набор стенсилов Visio, которые можно использовать для рисования схем в своем ЦОД:

Стенсилы включают в себя следующие компоненты:

• Host
• Cluster
• Virtual SAN и физическая сеть зранения данных
• Тонкие и обычные хранилища
• Различные типы облаков в датацентре: Public, Private, Hybrid и Virtual Datacenter
• некоторые другие объекты

Также напомним, что у компании Veeam, производителя решения номер 1 для резервного копирования виртуальных сред Veeam Backup and Replication, также есть свои стенсилы для Visio:

Там вы найдете следующие объекты:

• Хосты ESXi и Hyper-V
• Датацентры
• Объекты SCVMM
• Локальные и общие хранилища
• LUN
• Виртуальные машины и их статус (запущена, остановлена)
• Сетевые адаптеры (NIC)
• И многое другое

Этих двух наборов будет вполне достаточно, чтобы набросать простенькую схемку при планировании небольшой инфраструкутры.

У многих администраторов VMware vSphere зачастую возникает необходимость понизить версию виртуального аппаратного обеспечения (hardware version) виртуальной машины. Это может понадобиться в следующих случаях (и не только):

• когда толстый клиент vSphere Client не поддерживает всех функций новой версии Virtual Hardware
• новая версия железа не поддерживается старыми хостами VMware ESXi, которые вы еще не успели обновить
• если вы пользуетесь услугами внешнего провайдера IaaS (аренда виртуальных машин), то у провайдера может оказаться не самая последняя версия платформы, и при миграции в его облако обновленное Virtual Hardware не будет поддерживаться

Так или иначе, сделать даунгрейд виртуального железа можно, и это достаточно просто. Если апгрейд делается из контекстного меню виртуальной машины в vSphere Client:

То даунгрейд можно сделать одним из трех способов:

1. Перед апгрейдом виртуального обеспечения нужно сделать снапшот виртуальной машины. При откате к нему произойдет и откат к предыдущей версии виртуального железа.
2. Можно использовать VMware Converter Standalone для V2V-миграции, при которой можно выбрать нужную версию Virtual Hardware.
3. Можно создать новую виртуальную машину с нужной версией железа (например, на старом хосте ESXi), к которой прицепить диск от исходной ВМ.

Многие из вас знают о решении StarWind Virtual SAN, предназначенном для создания отказоустойчивых хранилищ. Но не все в курсе, что у StarWind есть виртуальный модуль Virtual SAN OVF (ссылка на его загрузку высылается по почте), который представляет собой шаблон виртуальной машины в формате OVF готовый к развертыванию на платформе VMware vSphere.

Недавно компания StarWind выпустила документ Virtual SAN OVF Deployment Guide, в котором описана процедура развертывания данного виртуального модуля.

Поскольку Microsoft на уровне лицензии запрещает распространение таких виртуальных модулей с гостевой ОС Windows в формате виртуальных дисков VMDK, придется сделать несколько дополнительных операций по развертыванию, а именно:

1. Запустить StarWind V2V Converter.
2. Преобразовать VHDX-диски в формат VMDK.
3. Поместить VMDK и OVF в одну папку.
4. Развернуть OVF на сервере VMware ESXi.
5. Заполнить поля IP-адреса для включения машины в виртуальную сеть.
6. Подождать окончания процесса создания и конфигурации виртуальной машины.

Больше подробностей о виртуальном модуле StarWind Virtual SAN OVF вы найдете в документе.

Компания Код Безопасности, производитель решений номер 1 для защиты виртуальных сред, выпустила обновление продукта vGate R2 (версия 2.8). Эта версия прошла инспекционный контроль в ФСТЭК России (с подтверждением выданных ранее сертификатов соответствия от 28.03.2011 № 2308 и от 12.07.2011 № 2383) и доступна для загрузки и покупки.
Таги: vGate, Update, Security, VMware, vSphere, Microsoft, Hyper-V, Security Code

Как начать с работать с кластерами хранилищ - документ VMware Virtual SAN 6.0 Proof of Concept Guide.

Не так давно компания VMware выпустила интересный документ "VMware Virtual SAN 6.0 Proof of Concept Guide", который позволяет представить себе в голове план пошаговой имплементации решения VSAN во всех его аспектах (хосты ESXi, настройка сети, тестирование решения, производительность, средства управления и т.п.).

Процесс, описанный в документе, представляет собой развертывание кластера Virtual SAN в изолированной среде для целей тестирования, чтобы обкатать решение в небольшой инфраструктуре и потом уже отправить его в производственную среду.

Основные разделы документа освещают следующие темы:

• Подготовительные работы
• Настройка сетевого взаимодействия
• Включение функций кластера хранилищ
• Функциональность платформы VMware vSphere при операциях в кластере VSAN
• Масштабирование кластера VSAN на несколько узлов
• Политики хранилищ
• Мониторинг состояния кластера
• Тестирование производительности
• Симуляция аппаратных отказов и тестирование поведения кластера
• Управление кластером Virtual SAN

Сам документ содержит 170 страниц и представляет собой ну очень детальное руководство по развертыванию кластера Virtual SAN и его тестированию. Причитав его, вы поймете множество интересных технических особенностей, касающихся принципов работы решения.

Скачать "VMware Virtual SAN 6.0 Proof of Concept Guide" можно по этой ссылке.

Многие из вас знают, что в период с 12 по 15 октября, традиционно в Барселоне, пройдет очередной VMworld Europe 2015.

Недавно на соответствующем ресурсе компания VMware опубликовала список сессий и спикеров предстоящей конференции:

Из интересного (взято у Дункана Эппинга, вбивайте номер сессии в поиск):

• HBC5008 – vCloud Air Disaster Recovery Technical Deep Dive
• INF5060 – What’s New in vSphere?
• STO5877 – What’s New in Virtual SAN 6.1
• EUC5762 – End-to-end Security with AirWatch, VMware NSX and Intelligent Networking
• INF4528 – vCenter Server Appliance (VCSA) Best Practices & Tips/Tricks – William Lam
• INF5211 – Automating Everything VMware with PowerCLI – Deep Dive – Alan Renouf & Luc Dekens
• STO4949 – Extreme Performance Series: Virtual SAN Performance Deep-Dive – Lenin Singaravelu & Sankaran Sivathanu
• NET4989 – The Future of Network Virtualization with VMware NSX – Bruce Davie
• STO6228 – Monitoring and Troubleshooting Virtual SAN, Current and Future – Christian Dickmann & Cormac Hogan
• CNA6649-S – Build and run Cloud-Native Apps in your Software-Defined Data Center – Kit Colbert & Aaron Sweemer & Jared Rosoff
• VAPP4639 – Best Practices for Performance Tuning of Virtualized Telco and NFV Applications on vSphere ESXi – Bhavesh Davda & Jin Heo
• STO4649 – Virtual Volumes Technical Deep Dive – Ken Werneburg & Patrick Dirks
• NET5612 – NSX for vSphere Logical Load Balacing Deep Dive – Dimitri Desmidt & Uday Masurekar
• INF5701 – Extreme Performance Series: vSphere Compute & Memory – Fei Guo & Seong Beom Kim
• CTO6455 – Future Meets Present: Insights from VMware’s Field CTOs – Joe Baguley & Chris Wolf & Paul Strong
• INF5306 – DRS Advancements in vSphere 6, Advanced Concepts, and Future Directions – Naveen Nagaraj
• STO5336 – VMware Virtual SAN – Architecture Deep Dive – Christos Karamanolis & Rawlinson Rivera
• INF4529 – VMware Certificate Management for Mere Mortals – Adam Eckerle & Ryan Johnson
• STO6287-SPO – Instant Application Recovery and DevOps Infrastructure for VMware Environments – A Technical Deep Dive – Chris Wahl & Arvind Nithrakashyap
• INF4535 – 5 Functions of Software Defined Availability – Frank Denneman & Duncan Epping
• STO5333 – Building a Stretched Cluster with Virtual SAN – Rawlinson Rivera & Duncan Epping
• SDDC5027 – VCDX Unwrapped – Everything You Wanted to Know About VCDX – Panel
• STO4650-QT – Five Common Customer Use Cases for Virtual SAN – Lee Dilworth & Duncan Epping

Ну и кому интересно - небольшое видео о том, зачем ехать на VMworld в Барсу:

Недавно компания VMware выпустила очень интересный документ "What’s New in VMware vSphere 6 - Performance", в котором рассказывается о том, какие улучшения были сделаны в новой версии vSphere 6.0, касающиеся различных аспектов производительности платформы (вычислительные ресурсы, хранилища и сети).

Документ выпущен отделом технического маркетинга VMware, и в нем приведены вполне конкретные сведения об увеличении производительности компонентов vSphere.

Например, вот сводная картинка улучшения производительности vCenter (версия 6.0 против 5.5) при тяжелых нагрузках на Microsoft SQL Server 2012 в зависимости от числа объектов, которые находятся под управлением сервиса (размер Inventory). Данные приведены в количестве операций в минуту. Результаты впечатляют:

Улучшения кластеров отказоустойчивых хранилищ VMware Virtual SAN (результаты по конфигурации All-Flash еще не обработаны):

С точки зрения производительности виртуальных сетевых адаптеров VMXNET 3, платформа vSphere 6.0 научилась выжимать из них более 35 гигабит в секунду при работе с физическими адаптерами 40 GbE:

Ну и в целом в документе есть еще много чего интересного - скачивайте.

На одном из блогов о виртуализации на платформе VMware появилась интересная утилита VLANidentificator, предоставляющая информацию о принадлежности всех ваших виртуальных машин к портгруппам виртуальных коммутаторов и их VLAN ID:

Вы просто вводите стартовый IP-адрес и подсеть для сканирования, а скрипт пробегается по всем хостам VMware ESXi и vCenter, после чего все данные помещаются в сводную таблицу, в которой вы можете проверить, что нужные машины находятся в нужных VLAN, а также посмотреть на каких хостах ESXi они сейчас размещены. Для показа полной информации о машине, в том числе IP-адреса, нужно чтобы в ВМ были установлены VMware Tools.

Утилитка требует PowerShell 3 и более поздней версии и протестирована для работы с VMware vSphere 5.0, поэтому с шестой версией вполне может не работать. Поддерживаются также и распределенные виртуальные коммутаторы VMware Distributed Switch (vDS).

Исполняемый файл VLANidentificator можно скачать по этой ссылке. Ну а исходный код можно скачать вот тут.

Есть такая штука в сфере ИБ - Security banner. Это когда при логине в какую-нибудь консоль вы выводите пользователю сообщение о характере информации и системы, к которой он пытается получить доступ, и предупреждаете о возможной ответственности за несанкционированный доступ. Вряд ли это много кого остановит, но все же с ним лучше, чем без него.

Вот способ сделать security banner для VMware ESXi. В VMware vSphere он бывает двух видов:

1. Login banner

Это текст, который показывается после ввода имени пользователя, но до ввода пароля:

Чтобы его поменять нужно залогиниться на хост VMware ESXi и с помощью редактора vi или nano отредактировать следующий файл:

# vi /etc/issue

Нажмите клавишу <i>, чтобы перейти в режим редактирования. После того, как вы внесете нужные изменения, нажмите <esc> и потом напишите ZZ, после чего нажмите ввод, чтобы сохранить изменения. Затем перезагрузите демон SSH следующей командой:

# /etc/init.d/SSH restart

2. Баннер MOTD.

Это баннер, который показывают пользователю после успешного логина по SSH. Чтобы задать его (по умолчанию он пустой), нужно отредактировать следующий файл через vi:

# vi /etc/motd

Также можно не лазить на хост VMware ESXi, а открыть vSphere Web Client, перейти в Manage->Settings и в разделе Advanced System Settings поискать по строчке "etc.". Там будет 2 параметра:

• Config.Etc.issue - это текст для security banner
• Config.Etc.motd - текст для баннера motd

То же самое можно сделать и в толстом клиенте vSphere Client:

Время от времени у пользователей VMware vSphere возникает ошибка, связанная с тем, что виртуальный диск VMDK виртуальной машины оказывается залоченным (то есть эксклюзивно используемым процессом VMX одного из хостов ESXi). В этом случае виртуальная машина не отвечает на попытки включить ее или переместить на другой хост-сервер средствами VMware vMotion. При этом процесс vmx вполне может быть запущен не на том хосте ESXi, на котором машина отображается в VMware vSphere Client или Web Client. Такое может случиться при падении хоста ESXi, массовом отключении питания или неполадках в сети SAN, а также и в некоторых других случаях.

Например, может быть вот такое сообщение об ошибке при включении машины:

Could not power on VM: Lock was not free

Для решения проблемы вам нужно найти хост ESXi, который исполняет vmx-процесс машины, и убить ВМ, которая не отвечает. После этого можно будет использовать VMDK-файл этой машины, а также включить ее, если она не работает.

Делается это следующим образом:

1. Находим хост, исполняющий vmx-процесс виртуальной машины с залоченным VMDK.

Для этого заходим по SSH на один из серверов ESXi (эта процедура работает для версий vSphere 5.5 P05 и 6.0, а также более поздних) и переходим в папку /bin:

#cd /bin

С помощью утилиты vmfsfilelockinfo ищем владельца лока нужного VMDK-файла:

~ # vmfsfilelockinfo -p /vmfs/volumes/iscsi-lefthand-2/VM1/vm1.vmdk -v 192.168.1.10 -u administrator@vsphere.local

Здесь vm1.vmdk - наш залоченный виртуальный диск, а 192.168.1.10 - IP-адрес сервера VMware vCenter. Вам потребуется ввести пароль его администратора.

Вывод будет примерно таким:

vmfsflelockinfo Version 1.0
Looking for lock owners on "VM1_1-000001-delta.vmdk"
"VM1_1-000001-delta.vmdk" is locked in Exclusive mode by host having mac address ['00:50:56:03:3e:f1']
Trying to make use of Fault Domain Manager
----------------------------------------------------------------------
Found 0 ESX hosts using Fault Domain Manager.
----------------------------------------------------------------------
Could not get information from Fault domain manager
Connecting to 192.168.1.10 with user administrator@vsphere.local
Password: xXxXxXxXxXx
----------------------------------------------------------------------
Found 3 ESX hosts from Virtual Center Server.
----------------------------------------------------------------------
Searching on Host 192.168.1.178
Searching on Host 192.168.1.179
Searching on Host 192.168.1.180
MAC Address : 00:50:56:03:3e:f1

Host owning the lock on the vmdk is 192.168.1.180, lockMode : Exclusive

Total time taken : 0.27 seconds.

Из вывода можно понять 2 важные вещи:

• MAC-адрес хоста, залочившего VMDK
• IP-адрес хоста, залочившего VMDK
• Тип лока - Exclusive

Кстати, лок может быть нескольких типов:

• mode 0 - нет лока
• mode 1 - эксклюзивный лок (vmx-процесс машины существует и использует VMDK-диск)
• mode 2 - лок только для чтения (например, для основного диска, в случае если у него есть снапшоты)
• mode 3 - лок для одновременной записи с нескольких хостов (например, для кластеров MSCS или ВМ, защищенных технологией VMware Fault Tolerance).

Более подробно об этом написано в KB 2110152.

2. Точно определяем хост, машина которого держит VMDK.

Если IP-адрес показан - хост определен. Если, мало ли, по какой-то причине его нет, можно ориентироваться на MAC-адрес. Выяснить его можно следующей командой на хосте ESXi:

# vim-cmd hostsvc/net/info | grep "mac ="

3. Обнаруживаем процесс VMX, который держит VMDK.

Выполняем на найденном ESXi команду:

# lsof | egrep 'Cartel|vm1.vmdk'

Получаем что-то вроде этого:

Cartel | World name | Type | fd | Description
36202 vmx FILE 80 /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/VM1/vm1.vmdk

Мы нашли Cartel ID нужного процесса VMX (36202). Теперь выполняем команду, чтобы найти ее World ID:

# esxcli vm process list

Получаем такой вывод:

Alternate_VM27
World ID: 36205
Process ID: 0
VMX Cartel ID: 36202
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a9 dc 9f bf
Display Name: Alternate_VM27
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM27/Alternate_VM27.vmx


Alternate_VM20
World ID: 36207
Process ID: 0
VMX Cartel ID: 36206
UUID: 56 4d bd a1 1d 10 98 0f-c1 41 85 ea a5 dc 94 5f
Display Name: Alternate_VM20
Config File: /vmfs/volumes/556ce175-7f7bed3f-eb72-000c2998c47d/Alternate_VM20/Alternate_VM20.vmx
...

Видим, что World ID нашей машины - 36205.

4. Убиваем VMX-процесс, залочивший VMDK.

Ну и убиваем зависший процесс VMX следующей командой:

# esxcli vm process kill --type force --world-id <ID>

После этого с машиной и ее диском можно делать уже что требуется.

Также для более ранних версий VMware vSphere посмотрите нашу статью вот здесь.